home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / mail / mime-faq / part3 < prev    next >
Internet Message Format  |  1994-03-21  |  16KB
  1. Path: bloom-beacon.mit.edu!hookup!news.moneng.mei.com!howland.reston.ans.net!pipex!pipex!not-for-mail
  2. From: tim@pipex.net (Tim Goodwin)
  3. Newsgroups: comp.mail.mime,comp.answers,news.answers
  4. Subject: comp.mail.mime frequently asked questions list (FAQ) (3/3)
  5. Supersedes: <mime-faq3_760907132@pipex.net>
  6. Followup-To: comp.mail.mime
  7. Date: 21 Mar 1994 19:52:15 -0000
  8. Organization: Pipex Ltd., 216 Science Park, Cambridge CB4 4WA, England
  9. Lines: 338
  10. Approved: news-answers-request@MIT.Edu
  11. Expires: 14 May 1994 19:51:54 GMT
  12. Message-ID: <mime-faq3_764279514@pipex.net>
  13. References: <mime-faq1_764279514@pipex.net>
  14. NNTP-Posting-Host: tank.pipex.net
  15. Mime-Version: 1.0
  16. Content-Type: message/partial; number=3; total=3; id="<mime_764279514@pipex.net>"
  17. Content-Transfer-Encoding: 7bit
  18. Summary: This posting contains answers to some of the Frequently Asked
  19.     Questions about MIME (Multipurpose Internet Mail Extensions).
  20.     Please read it before posting a question to comp.mail.mime.
  21. Xref: bloom-beacon.mit.edu comp.mail.mime:2932 comp.answers:4276 news.answers:16702
  22.  
  23. Archive-Name: mail/mime-faq/part3
  24. Last-modified: 1994/02/10
  25. Version: 3.4
  26.  
  27.  
  28. comp.mail.mime frequently asked questions list (FAQ) (3/3)
  29.  
  30. Part III -- Advanced Topics
  31.  
  32. This is part III of a Frequently Asked Questions document about MIME, the
  33. multipurpose and multi-media standard for Internet mail.
  34.  
  35. Part I covers frequently asked questions.
  36.  
  37. Part II is a listing of MIME products.
  38.  
  39. Part III covers advanced topics.
  40.  
  41.  
  42. 10 Information
  43.  
  44. 10.1 MIME-relevant RFCs and other standards
  45.  
  46. The RFCs mentioned here are mainly relevant to people building MIME
  47. software.  As an end user, if your mail system is nice to you, you
  48. won't really have to know very much about these things.
  49.  
  50. RFC and Internet-Drafts are available by anonymous FTP from any decent
  51. archive site.  If you're really stuck, try
  52.  
  53. FTP:      ds.internic.net:rfc/*
  54. FTP:      ds.internic.net:internet-drafts/*
  55.  
  56. MIME is defined in RFC 1521 (MIME Mechanisms for Specifying and
  57. Describing the Format of Internet Message Bodies) and RFC 1522
  58. (Representation of Non-ASCII Text in Internet Message Headers).
  59.  
  60. These are Internet standards-track protocols.  For the full
  61. implications of this, see RFC 1540 (IAB Official Protocol Standards).
  62. Here is their current status.
  63.  
  64.     1521: Draft Elective Standard
  65.     1522: Draft Elective Standard
  66.  
  67. These two RFCs do not fully define MIME.  For one thing, they are
  68. based on RFC 822 (Standard for the format of ARPA Internet text
  69. messages), as revised by RFC 1123 (Requirements for Internet hosts -
  70. application and support) and must be read in conjunction with these.
  71.  
  72. For another, they are extensible.  See 10.2 for a complete list of
  73. registered subtypes.
  74.  
  75. There are a whole lot of other RFCs that deal with email, including
  76. these.
  77.  
  78. IAB standards-track RFCs
  79.  
  80.     1502  X.400 Use of Extended Character Sets
  81.     1496  Rules for Downgrading Messages from X.400(88) to X.400(84)
  82.           when MIME Content-Types are Present in the Messages
  83.     1495  Mapping between X.400 and RFC-822 Message Bodies
  84.     1494  Equivalences between 1988 X.400 and RFC-922 Message Bodies
  85.     1427  SMTP Service Extension for Message Size Declaration.
  86.     1426  SMTP Service Extension for 8bit-MIMEtransport.
  87.     1425  SMTP Service Extensions.
  88.     1424  Privacy Enhancement for Internet Electronic Mail: Part IV.
  89.     1423  Privacy Enhancement for Internet Electronic Mail: Part III.
  90.     1422  Privacy Enhancement for Internet Electronic Mail: Part II.
  91.     1421  Privacy Enhancement for Internet Electronic Mail: Part I.
  92.     1327  Mapping between X.400(1988)/ISO 10021 and RFC 822.
  93.     1314  File format for the exchange of images in the Internet.
  94.  
  95. Other RFCs (Informational, Experimental, or Historical)
  96.  
  97.     1489  Registration of a Cyrillic Character Set.
  98.     1468  Japanese Character Encoding for Internet Messages.
  99.     1456  Conventions for Encoding the Vietnamese Language.
  100.     1428  Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME.
  101.     1357  Format for emailing bibliographic records.
  102.     1345  Character Mnemonics & Character Sets.
  103.     1344  Implications of MIME for Internet mail gateways.
  104.     1343  User agent configuration mechanism for multimedia mail format
  105.           information.
  106.     1339  Remote mail checking protocol.
  107.     1321  MD5 Message-Digest algorithm.
  108.     1225  Post Office Protocol: Version 3.
  109.     1211  Problems with the maintenance of large mailing lists.
  110.     1176  Interactive Mail Access Protocol: Version 2.
  111.     1197  Using ODA for translating multimedia information.
  112.     1154  Encoding header field for internet messages.
  113.     1153  Digest message format.
  114.     1049  Content-type header field for Internet messages.
  115.     1036  Standard for interchange of USENET messages.
  116.     934   Proposed standard for message encapsulation.
  117.     807   Multimedia mail meeting notes.
  118.  
  119.  
  120. 10.2 List of registered MIME types
  121.  
  122. A list of registered MIME types is available from
  123.  
  124. FTP:      isi.edu:in-notes/media-types/media-types
  125.  
  126. This is the latest version.
  127.  
  128. Type            Subtype                Description          Reference
  129. ----            -------                -----------          ---------
  130. text            plain                                       [169,NSB]
  131.                 richtext                                    [169,NSB]
  132.                 tab-separated-values                   [Paul Lindner]
  133.  
  134. multipart       mixed                                       [169,NSB]
  135.                 alternative                                 [169,NSB]
  136.                 digest                                      [169,NSB]
  137.                 parallel                                    [169,NSB]
  138.                 appledouble                [MacMime,Patrik Faltstrom]
  139.                 header-set                             [Dave Crocker]
  140.  
  141. message         rfc822                                      [169,NSB]
  142.                 partial                                     [169,NSB]
  143.                 external-body                               [169,NSB]
  144.                 news                        [RFC 1036, Henry Spencer]
  145.  
  146. application     octet-stream                                [169,NSB]
  147.                 postscript                                  [169,NSB]
  148.                 oda                                         [169,NSB]
  149.                 atomicmail                           [atomicmail,NSB]
  150.                 andrew-inset                       [andrew-inset,NSB]
  151.                 slate                           [slate,terry crowley]
  152.                 wita              [Wang Info Transfer,Larry Campbell]
  153.                 dec-dx            [Digital Doc Trans, Larry Campbell]
  154.                 dca-rft        [IBM Doc Content Arch, Larry Campbell]
  155.                 activemessage                          [Ehud Shapiro]
  156.                 rtf                                    [Paul Lindner]
  157.                 applefile                  [MacMime,Patrik Faltstrom]
  158.                 mac-binhex40               [MacMime,Patrik Faltstrom]
  159.                 news-message-id             [RFC 1036, Henry Spencer]
  160.                 news-transmission           [RFC 1036, Henry Spencer]
  161.                 wordperfect5.1                         [Paul Lindner]
  162.                 pdf                                    [Paul Lindner]
  163.                 zip                                    [Paul Lindner]
  164.                 macwriteii                             [Paul Lindner]
  165.                 msword                                 [Paul Lindner]
  166.                 remote-printing                         [RFC1486,MTR]
  167.  
  168. image           jpeg                                        [169,NSB]
  169.                 gif                                         [169,NSB]
  170.                 ief             Image Exchange Format      [RFC-1314]
  171.                 tiff            Tag Image File Format           [MTR]
  172.  
  173. audio           basic                                       [169,NSB]
  174.  
  175. video           mpeg                                        [169,NSB]
  176.                 quicktime                              [Paul Lindner]
  177.  
  178. Each <type> has a directory
  179.  
  180. FTP:      isi.edu:in-notes/media-types/<type>
  181.  
  182. containing the definitions of its subtypes.
  183.  
  184.  
  185. 10.3 Internet Engineering Task Force (IETF) working groups
  186.  
  187. The IETF working group on Privacy-Enhanced Mail (PEM) has developed
  188. extensions that permit confidentiality, authentication, and integrity to
  189. be provided in a manner backwards compatible with RFC-821 and RFC-822
  190. (see 3.4).  Work is underway to align PEM and MIME which will provide
  191. real security to MIME email.
  192.  
  193. The IETF MIME working group is not actively considering significant
  194. changes to the specifications.  However the WG still exists as a forum
  195. for MIME developers, as a home for interpretation questions, and to
  196. handle any problems or ambiguities that might arise in MIME.
  197.  
  198.  
  199. 11 Developers' FAQs
  200.  
  201. 11.1 How can I register a new MIME type?
  202.  
  203. The procedures for registering new content types, character set
  204. values, access types, and conversions parameters with IANA (the
  205. Internet Assigned Numbers Authority) are documented in RFC 1521.
  206.  
  207.  
  208. 11.2 What's ESMTP, and how does it affect MIME?
  209.  
  210. ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
  211. extensions to "traditional" (RFC 821) SMTP can be negotiated by client
  212. and server.  The mechanism (RFC 1425) is open-ended; so far two
  213. extensions have been defined.
  214.  
  215. Message size declaration (RFC 1427) offers a graceful way for servers
  216. to limit the size of message they are prepared to accept.  (With SMTP,
  217. the only possibility is for the server to discard the message after it
  218. has been sent in its entirety.  There is no way for the client to know
  219. that it was the size of the message that caused the problem.)
  220.  
  221. When a message is returned to the user as being too large to deliver,
  222. one possible approach might be to fragment the message using the MIME
  223. Message/Partial mechanism, and resubmit it.
  224.  
  225. Depending on the exact reason for the "too large" rejection, this may
  226. or may not be a good idea.  For example, the limitation may reflect
  227. the recipient's disk quota, in which case the fragmented message will
  228. not be fully deliverable either.
  229.  
  230. The possibility of fragmentation should, therefore, be left to the
  231. user's discretion (not performed automatically by the SMTP client).
  232.  
  233. 8bit-MIMEtransport (RFC 1426) opens up the possibility of sending 8bit
  234. data in mail messages, without having to use base64, quoted-printable,
  235. or another encoding, and without the breakage that can result from
  236. sending 8bit data to an unsuspecting RFC 821 SMTP server.  RFC 1428
  237. (Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
  238. discusses some of the implications of this.
  239.  
  240.  
  241. 11.3 Where can I get some sample MIME messages?
  242.  
  243. FTP:      thumper.bellcore.com:pub/nsb/samples/*
  244.  
  245.  
  246. 11.4 Wouldn't MIME be better if it did <foo>?
  247.  
  248. This question is asked for various values of <foo>.  Perhaps the most
  249. common is "multilevel encodings": see the next question.  There are
  250. a couple general points that apply to all <foo>.
  251.  
  252. 1. Please remember that MIME is the result of a lot of work by a lot
  253. of people, over a long time (look at the Acknowledgements section of
  254. RFC 1521).  A great many ideas, probably including yours, were
  255. considered.  In many cases, there were conflicting goals, such as
  256. simplicity and interoperability on the one hand, and power and
  257. flexibility on the other.
  258.  
  259. 2. If you really think you've got an original idea which would improve
  260. MIME, the correct place to pursue it is not this newsgroup, but the
  261. working group mailing list (having first read the archives, to check
  262. that it really is new).  Yes, this is going to be a lot more work than
  263. posting a news article.
  264.  
  265.  
  266. 11.5 So what about multilevel encodings?
  267.  
  268. MIME uses a two-level encoding scheme.  The original object (for
  269. example, a picture, or a text document) is encoded using a well
  270. defined mechanism appropriate to that object (perhaps GIF for the
  271. picture, and text/enriched for the document).  Then a second encoding
  272. is used to ensure that the first encoding can be transmitted intact
  273. (probably base64 for the GIF, and quoted printable for the
  274. text/enriched document).  
  275.  
  276. Note that there is a very small number of the second encodings (five,
  277. but three of these are simply indications of what kind of data an
  278. unencoded body part contains), and it is not expected that there will
  279. be many more in the foreseeable future.
  280.  
  281. The multilevel encodings idea is for a more generalized MIME-like
  282. encoding mechanism that could indicate many arbitrary transformations
  283. of the original object.  For example,
  284.  
  285.     Content-Type: application/tar; conversions="encrypt,compress,uuencode"
  286.  
  287. might indicate a UNIX tar file that had been encrypted, then
  288. compressed, then uuencoded.  (This is a fictitious example of how MIME
  289. might have worked; it's not legal MIME.  Don't worry if you've never
  290. heard of some of these transformations.)
  291.  
  292. This may look like an attractive scheme at first, but it has a number
  293. of problems.
  294.  
  295. 1. If you've been brought up on UNIX and command pipelines, the
  296. implementation of such a scheme seems trivial.  Surely any half-decent
  297. machine can do something similar?  Unfortunately, this turns out to be
  298. true only for a very restricted definition of "half-decent".  In
  299. practice, it would be awfully difficult to implement this on a lot of
  300. systems.  Probably even more systems would not allow new
  301. transformations to be just "slotted in", and would require
  302. recompilation or reshipping whenever a new one came along.
  303.  
  304. 2. Each successive transformation reduces the size of the audience who
  305. can successfully decode the message.  Every MIME mailer must be able
  306. to decode base64 and quoted-printable, so it's guaranteed that you can
  307. at least get back to the raw data.  What if, in the above example, I
  308. have tar, decrypt, uudecode, but no uncompressor?
  309.  
  310. 3. Such a scheme does not increase the scope of the framework defined
  311. by MIME.  If uuencoded, compressed, encrypted tar files are useful
  312. things to sling around, it is entirely possible to define a new MIME
  313. type (presumably a subtype of application) to handle them.
  314.  
  315.  
  316. 11.6 Why doesn't MIME include a mechanism for compression?
  317.  
  318. Compression is a difficult area.  It was considered by the working
  319. group, but no consensus was reached.  There is still work going on in
  320. this area: there may someday be a compressed-64 encoding.
  321.  
  322. Most compression algorithms have one of more of these undesirable
  323. properties: they are covered by patent, they require the ability to
  324. treat the input as a stream of bits, they use a large data space.  The
  325. chances of finding a truly interoperable compression algorithm are
  326. therefore rather slim.
  327.  
  328. It is worth noting that most or all of the image and video subtypes
  329. (including GIF, JPEG, TIFF, and MPEG) define their own compression
  330. schemes.
  331.  
  332.  
  333. 12 Acknowledgements
  334.  
  335. Many people have contributed to this document.
  336.  
  337. They include: 
  338.  
  339. Alan Robiette, Alec Henderson, Axel Boldt, Carlyn Lowery, Chris Pepper,
  340. Christophe Wolfhugel, Christopher Davis, Craig Huckabee, Daniel
  341. Fandrich, Daniel Glazman, Dave Curry, Dave Lacey, David Collier-Brown,
  342. David Miller, Ed Anselmo, Edward Vielmetti, Erik van der Poel, Harald
  343. Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay Weber, Jerry Sweet,
  344. Joe Ilacqua, Joergen Haegg, John Gardiner Myers, John Martin, John
  345. Romine, Joyce Reynolds, Keith Moore, Larry Salomon Jr, Lars-Gunnar
  346. Olsson, Luc Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand,
  347. Marshall Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael
  348. Urban, Nathaniel Borenstein, Ned Freed, Niklas Agren, Pat Farrell, Paul
  349. Eggert, Piero Serini, Quentin Smart, Ran Atkinson, Ray Langford, Rich
  350. Ragan, Rick Troth, Ron Barak, Steve Dorner, Steve Hole, Stuart Lynne,
  351. Susan Straub, Syd Weinstein, Tim Kehres, Tommy Wallo, Yehavi Bourvine.
  352.  
  353. If I've left your name off, please accept my apologies.  Drop me a
  354. note and I'll include it for next time.
  355.  
  356. Thanks also to Jonathan Kamens, for coordinating the *.answers groups,
  357. and for his post_faq program which brought you this FAQ.
  358.  
  359.  
  360. End of Part III
  361.